home *** CD-ROM | disk | FTP | other *** search
/ Ham Radio 2000 / Ham Radio 2000.iso / ham2000 / packet / aprs75c / ideas.txt < prev    next >
Text File  |  1995-06-08  |  5KB  |  97 lines
  1. IDEAS.txt 7.0      OTHER SUGGESTED IDEAS FOR SOFTWARE WRITERS!
  2.  
  3. Don't let me have all the fun.  There are lots of additional utilities and
  4. other neat applications for APRS waiting to be written!  Please consider
  5. taking one of these on...
  6.  
  7. WIDE-N UNIVERSAL DIGIPEAT MODE!
  8.  
  9.     This may be the simplest mechanism for making an order of magnitude
  10. improvement in APRS status and position reporting networks.  In a WIDE-N
  11. network, each WIDE digi simply repeats ANY packet with the VIA address of
  12. WIDE-N; but ONLY ONCE.  It subtracts 1 from the SSID and then keeps a
  13. copy of the last 30 seconds of packets (or just a checksum of each one),
  14. and compares each new packet that it hears with the LAST ones that it
  15. digipeated.  This way it avoids TRANSMITting it again!  This simple
  16. algorithm could develop into the ULTIMATE GENERIC MOBILE GPS NETWORK! 
  17. Mobiles traveling within a 100 mile radius of home could simply set a
  18. path of UNPROTO APRS VIA WIDE-3 without fear of clogging the network! 
  19. This WIDE-N ROM would not have to do anything else!  For more details
  20. see DIGIS.TXT.
  21.  
  22.  
  23.  
  24. LEVEL FOUR UI FRAME ROUTING!  (this idea IS OBE if the WIDE-N idea works)
  25.  
  26.     For people with the ability to write code for TAPR-2 clones, there is
  27. a real nead for LEVEL-4 distribution of APRS UI frames through a network.
  28. Rather than using dumb digipeaters with the generic RELAY and WIDE callsigns,
  29. the level-4 network should only need the single NODE-NAME of the HOME
  30. or DESTINATION node for APRS UI frames.  The network should know the routing
  31. and paths to use to deliver the UI frame to that destination node.  There,
  32. the UI frame is transmitted ONCE (or maybe twice some time later) as if it
  33. had been originated locally.
  34.  
  35. Since APRS UI position reports are redundant, and rapidly become obsolete
  36. as they are refreshed by a moving station, the level-4 NETWORK only has to
  37. make a feeble attempt to route the packets to the desired destination HOME
  38. node.  They need not clutter the Nodes buffers, and can be time-ed out
  39. rather quickly.  For more thoughts on this subject, read the DIGIPTR.txt file.
  40.  
  41.  
  42. PRE-EMPTIVE DIGIPEATING (this idea may be OBE if the "ALL"net idea works)
  43.  
  44.     Until we get level-four routing of UI frames, it shuld be possible to
  45. modify TNC code for pre-emptive digipeating.  This means that a digipeater
  46. will look for its callsign ANYWHERE in the digi-calls list in a packet header
  47. and if it finds itself, it will go ahead and digipeat the packet and cancel
  48. all of the earlier digipeat bits.  This way a mobile only has to provide
  49. a list of DIGI calls in the fartherest sequence that he may travel, and his
  50. packets will all arrive at the last one in the list, no matter where along
  51. the string he is located!  See more in the DIGIPTR.txt file.
  52.  
  53.  
  54. AUTODF NETWORK
  55.  
  56.     Now, if you make an "ALL"net ROM for TNC digipeaters, then there should
  57. be plenty of room for adding the A/D routine to take the LIMITER current from
  58. a DF receiver at the same site, and converting that to a signal strength
  59. value.  Then transmitting that report in an APRS OMNI-SIGNAL-STRENGTH DF
  60. report.  This way, each APRS ALL digipeater site, could also be used as
  61. an OMNI-DF site for reporting DF signal strengths.  See the README\DF.txt
  62. file for details!
  63.  
  64.  
  65. CALLSIGN and POSITION DATABASE NETWORK SERVER
  66.  
  67.      Since APRS includes the single station QUERY format for requesting a
  68. station to respond with his position report, there is no reason why any PC
  69. interfaced with the HAMCALL CD ROM could not listen for such QUERYS, and
  70. respond with a properly formatted APRS POSITION report for that station!
  71. The APRS station sending the single UI frame QUERY gets rewarded by seeing
  72. the location of the requested station SHOW UP ON HIS MAP!  The database PC
  73. would of-course wait about 30 seconds to be sure the requested call is not
  74. LOCAL and then respond with an APRS OBJECT position report, which would
  75. include the station's name and address!
  76.  
  77.  
  78. ALL FUTURE TNC BEACON CODE:
  79.  
  80.     For future designs, the LOCATION TEXT and BEACON TEXT timing periods
  81. should be 1 minute for manual entries, but the LText UI frame should be sent 
  82. out ONCE everytime a new manual entry is made.  The ultimate objective for 
  83. all UI beacons should be to have the optional APRS DECAYING time period 
  84. algorithm built into all TNC's.  With the DECAY option, each new manual 
  85. entry of BText or LText will force a UI frame immediately, 15 sec later, 
  86. 30 after that, 60 after that, 2 mins, then 4 mins, then 8 mins and so on 
  87. to N minutes, and stay at N minutes forever.  This way, new UI information 
  88. is transmitted immediately to all stations on the net, but old beacons soon 
  89. fade away.  The minimum value of N for the DECAY option would be about 10 
  90. minutes with a default of 60.  One other addition to complete the APRS 
  91. philosophy, is to have the TNC respond with both its LText and BText 
  92. randomly within one minute of seeing an APRS query; a UI frame to the 
  93. address  of APRS with the text field set equal to ?APRS?.  This way, 
  94. stations could drop back to a decayed beacon rate of once every 4 hours or 
  95. so, but still would pop up on an APRS map if requested.
  96.  
  97.